In general terms, the present invention is concerned with mechanisms via which resources available on a network are updated to provide new functionality and/or content. One particularly noteworthy example of such a resource is an Internet website, where users may access information and/or conduct transactions, such as purchase goods, register for a seminar, or complete a survey. The content and functionality of the websites is embodied in bundles of software that execute on host servers that support the websites. From time to time, it may be necessary for the providers of the websites to update this software, to support new functionality and/or supply more current content. For example, a retailer may desire to update the software for its website on a weekly or monthly basis, to reflect changes in product inventory and/or prices. A newspaper may require much more frequent updates of its website's content, to ensure that the most current news is available to the users.
For some organizations that have websites, all activities associated with the website, including development, deployment and operation, are carried out within the organization, or otherwise under the organization's control. In such an environment, the organization has complete access to and understanding of all of the software that supports the website. This software can include high level graphical user interface code, the business logic code that underlies the display and document linking functionality of the website, the pages of content that are returned to users, and the application and operating system software for the servers that support the website. In such situations, the website operators are well-positioned to adapt the existing software and design and implement additional software as desired to change the appearance and/or functionality of the website.
As the e-commerce industry has continued to grow, the level of effort that is required to operate and maintain more complex and sophisticated websites has increased as well. This phenomenon has given rise to managed service providers (MSPs), wherein an organization that owns, or hosts, a website becomes a customer of the MSP, to whom it out-sources the operational aspects of running the website. In such a situation, however, the development of the underlying business logic code and website content typically remains with the customer. While this out-sourcing of website operation permits organizations to focus their resources on their core business, it also creates an environment where neither the developers of the website software nor the providers of the website infrastructure and operating software can independently introduce updates to either the content or the business logic associated with the website.
To address this situation, techniques have been developed to automatically deploy software that are particularly suited for those environments in which the management of the website operations is carried out by a party other than the organization that owns the website. One example of such a technique is disclosed in copending, commonly assigned U.S. application Ser. No. 09/699,346, the content of which is incorporated herein by reference. In general, the updating of the software that supports a resource on a network, such as an Internet website, is implemented in three main stages. Referring to FIG. 1, the first stage 10 comprises a development environment, in which the software is initially written and tested. The development environment is typically under the control of the organization that owns the website. Once the appropriate software has been developed, it is installed on an intermediate level server in a staging environment 12, where it can be tested under conditions that simulate those that might be experienced once it is fully deployed. The new software is tested under those conditions and, if it proves to be satisfactory, is then moved to the final stage 14, where it is installed on one or more production servers. If the organization that owns the website employs the services of an MSP, the operation of the production servers is controlled and monitored by the MSP. Typically, the staging server is housed in the same facility as the production servers, e.g. a data center 15, and is also under the control of the MSP.
In the technique disclosed in the previously cited application, the deployment of new software for a website begins with the customer uploading the new software to a storage site associated with the staging server. This storage site may be an internal drive of the server itself, or a central storage facility that is accessible by the server. Typically, the software is uploaded in an archived format, e.g. a zip or tar file. Once the software has been uploaded, the customer sends a request to the MSP to install the software on the staging server.
To install the software, it is first converted from its archived format into one or more installable packages. Examples of installable packages include RPM packages generated by the Redhat Package Manager associated with Linux and Unix operating systems, and MSI packages associated with Microsoft operating systems. Once they have been created, the packages are installed on the staging server, where they can be executed under typical operating conditions. If the customer is satisfied that the new software is functioning properly on the staging server, a request is sent to the MSP to deploy it to the production servers. In one implementation, the newly created installation packages are stored in a network file system, in response to the request. Thereafter, the MSP retrieves the installation packages stored in the network file system, and utilizes them to install the software on each of the production servers that support the customer's website. An advantage of storing the packages in the network file system is the fact that they are later available for ready installation in the case of disaster recovery, or if there is a need to upwardly scale the site by adding more servers.
It is an objective of the present invention to improve upon this type of software deployment operation. For example, as the complexity and sophistication of websites continues to grow, the amount of software necessary to support them also grows. In some examples, the amount of software that represents the business logic of the website might be as much as 4-6 gigabytes. The amount of time required to convert this much software from an archived format into an installable package can present a considerable performance bottleneck.
Another factor associated with the conversion of the software into installable packages is that it is atomic in nature. Namely, the entire set of business logic code for a given server is contained within the packages. Hence, even if the update represents a relatively small change from a prior version, the totality of the code is converted into installable packages.
As another consideration, the need to employ the services of MSP personnel in the software deployment process can present scheduling and/or logistical constraints that can delay the time at which the new software is deployed. Hence, it is desirable to provide a mechanism in which the customer can directly deploy the software onto a staging server without requiring the assistance of MSP personnel or the need to convert the software from one format into another before installation.